Retrieve the current Size Analysis status check rules configured for a project. Use this endpoint after receiving a `size_analysis.completed` webhook when you want external CI to evaluate the same Size Analysis status check thresholds that Sentry uses. The endpoint returns the current project configuration, not a historical snapshot from when the webhook was emitted. The response includes whether status check enforcement is enabled and the normalized rule list Sentry uses when evaluating Size Analysis thresholds. This endpoint requires a bearer token with `project:read` access. Project distribution tokens are not supported. Response notes: - `enabled: false` means status-check enforcement is disabled for the project. - `rules: []` means there are no configured thresholds to evaluate. - `value` is returned as a string. For `absolute` and `absolute_diff` measurements it is a byte value; for `relative_diff` it is a percentage. - `filterQuery` is the original configured filter string. - `filters` is the machine-readable version of `filterQuery`. - `filters: []` means the rule has no filters and applies to all builds. - `filters: null` means the saved filter query could not be parsed; Sentry's status check trigger treats that rule as non-matching. Rule evaluation semantics: - Threshold comparisons are strict: a rule triggers only when the computed value is greater than the configured threshold, not greater than or equal to it. - `absolute_diff` and `relative_diff` require a matching base metric/build. - `relative_diff` does not trigger when the base size is zero. - `artifactType` identifies the artifact scope the rule evaluates. `main_artifact`, `watch_artifact`, `android_dynamic_feature_artifact`, and `app_clip_artifact` target their matching artifact metric. `all_artifacts` evaluates all available artifact metrics. - Rule filters support the keys `app_id`, `git_head_ref`, `build_configuration_name`, and `platform_name`. - Filter objects are combined with AND. Multiple `conditions` inside one filter object are combined with OR. - Each condition uses `values`; single-value operators still return a one-item array. - Values in `filters` are decoded literal values for exact/simple operators, not query syntax. For example, `app_id:\*com` in `filterQuery` becomes `values: ["*com"]` with `operator: "equals"`. - The same key can appear in more than one filter object when positive and negative conditions both exist; those filter objects are still combined with AND. - Supported filter operators are `equals`, `notEquals`, `in`, `notIn`, `contains`, `notContains`, `startsWith`, `notStartsWith`, `endsWith`, `notEndsWith`, `matches`, and `notMatches`. - `matches` and `notMatches` values use Sentry wildcard pattern syntax, not regular expressions. `*` matches zero or more characters, escaped `\*` matches a literal asterisk, and a pattern without `*` is an exact match. - `in` and `notIn` are evaluated as one condition against all values, matching Sentry's status check trigger behavior. - A rule applies only when the build metadata matches all filters. If a referenced metadata key is missing, the filter does not match, even for negated operators.